Part 60: Assignment #29: Would You Believe It?

Would You Believe It?



That's... not where I thought that sentence was going.



OK, that honestly sounds like a cool idea. You could probably partner with other groups for this, too, not just athletic wear places - fashion houses, that sort of thing. And it sounds pretty simple, on the surface!

Mind you, if I've learned anything in this job, it's that the complicated things are simple, and the simple ones are complicated.






Oh. Oh dear. This is what Joe meant when he said automatic. So, just to recap, here's what I have to do, broken down into computer-friendly steps:

1. While the button is pushed, read sensor values and store them in a memory chip.
2. Once the button is un-pushed, turn those sensor values into color-bracket values and store them again, probably.
3. Figure out what the most populous color-value is.
4. Set the ink outputs to that color, according to this chart:



I don't know what 'n' and 'k' are supposed to mean in this context, but it does seem like the colors are arranged in a formation _kind of_ like the RGB color wheel.

This is definitely going to be a long and involved project, so I'll upload progress reports. But the result is going to be worth it...!

[ ~ ]



   

Here's my initial extremely prototype version. I've got the 'playback' chip on the right, which takes color (n and k) values from a ROM chip when signaled, and sends them to the outputs. (If you're wondering why there's no connection to the address line of the memory chip: another chip is going to set the address, and then the playback chip just reads the two values).

On the left side, there's the primary bucketer MC. As long as the button's held down, the MC will read from the sensor, divide the value by 10 using dst, and add 1 to that cell of the memory chip. (So a value of 20-29 increments cell 2, 40-49 increments cell 4, and so on.) Once the dust settles and the button is released, it'll send on x0 to let the next MC know it needs to read the memory chip and find the highest value. (An interesting side effect of this design is that red color values, which have the sensor numbers 20-39, occupy two slots in the memory chip, so the next MC will have to account for that.)

I still have to construct the MC which'll find the highest value and translate it into the correct color address for the color-values ROM, so that's next. I also need some way of erasing the sensor-connected memory chip once the color is passed to the output - this is so that the user can push the button more than once and the new sensor values don't have to compete against the ones read the first time. If I didn't erase the memory, the user would have to hold the button down longer and longer each time for it to read properly!

[ ~ ~ ]



     

I finished the second MC (the big one in the middle - I'm calling it the maximizer MC). It's responsible for figuring out which color value is highest (most common). The thing is, the design of the memory chips makes that... difficult to do.

The way you'd normally program an algorithm to find the biggest number in the set is to keep one variable that had the the highest value, and another for that value's position. You loop over each item in the set. If it's bigger than the biggest value we've seen so far, it becomes the new biggest, and we update the variables accordingly. The problem here is the memory chip's address pointer, which increments after each read. So, if you compare the current cell in the memory chip with the register holding the biggest value, you'll need to reset the address pointer to actually store that value later. Each address pointer reset is three lines of code ('mov x2 acc / sub 1 / mov acc x2), and the resulting algorithm is too big to fit, even in a MC6000.

What I ended up doing instead is to work with the memory chip, rather than against it. The MC takes things in two passes.
In the first pass, the MC moves each item in the memory chip into dat. acc is used to store the largest value seen so far. If dat is bigger than acc, it gets copied to acc immediately. The pass finishes with the biggest value in the memory chip in acc. There'll never be a tie, so if the MC happens on one, it knows it's gone around the the entire chip and it can stop. (This isn't that efficient, but I'll focus on improving the code in a later prototype.)
The second pass looks through the memory chip again to find that biggest value. When it finds it, it sends the address of it to the third MC, on the right. In theory. This design has a few problems, and I'm going to list what they are.

First off: I don't have enough spare pins on the maximizer MC to send the address value to the ROM with the color values and notify the MC on the right that sends those color values out. If I connect the middle MC, the right MC, and the ROM chip in a three-way connection like the pic above suggests, the memory chip will always snap the MC on the right out of its slx, because it always responds when anyone tries to read data. So, I might have to turn the MC on the right into a MC6000 so it can set the right address on the ROM chip itself.

Second, there's the little issue of the color red taking up two buckets. If you check on the datasheet above, you'll notice that values from 20-39 (a 20-item-wide set) are what the sensor gives when it sees something red. All the other colors only have 10-item-wide sets (40-49 for orange, 50-59 for yellow, and so on). Since I'm using dst to divide the sensor value by 10, then converting that directly into a memory address, red values will end up being put in cell 2 or cell 3 of the memory chip. I was originally intending to resolve this by putting code to sort it out on the middle MC, but it's full - which leads me into my third problem.

Third is the little issue of erasing the memory chip once the color has been passed to the output. I said in the previous section that I needed some way of erasing the memory, and the 'third pass' ('loop3') at the bottom of the maximizer MC is it. The only problem is that I don't have space to set the address on the memory chip beforehand, so it just erases the part of the chip from 'wherever the address pointer was' to (currently) the start, which might not be the whole chip under a lot of circumstances. I might not have enough space to do the erasing justice here.

I'll keep working on the design, and post another section when there's improvements.

[ ~ ~ ~ ]





       

This prototype works! Sort of. I was able to solve some of the problems, but not all of them— not yet, anyway.

I had to split the design of the initial bucketer across two MCs (both of which are on the left). The small bucketer MC, when given an address, reads that value from the memory chip and adds one to it. Then it stores the added-to value back in the same cell. (Assuming you pass it the same address twice, which the big bucketer always does). The extra space lets the big bucketer MC do one extra job: if the memory address to add to is '2', it bumps it up to '3' instead. This solves the problem of red having two separate buckets.

As I suggested above, the output MC (on the right) has been upgraded to a MC6000 (mostly for the extra pin, which lets it use two to talk to the ROM chip). It now takes the ID number of a color, fishes up the appropriate pair of cells from the ROM chip, and outputs them to the ink-n and ink-k outputs.

The only problem I haven't quite solved is erasing the memory chip once everything's properly output. The maximizer MC, in the middle, has had the first loop made more efficient, but I haven't seen any way to save the one line of code I'd need to get the erase to cover the entire chip. (The extra line would let me set the memory pointer to the start and have the loop finish once it loops back to the start. Right now I can only do one or the other.) Because of this, the memory chip doesn't get erased - meaning, the prototype works the first time you press the button after powering it on... and then it stays stuck that way until you reboot it.

I'll take one more crack at the design and see if I can fix this. I'm really close - I can feel it! And just as well, 'cause this one has been quite the struggle to put together.

[ ~ ~ ~ ~ ]





       


Sometimes the solution is staring you in the face, and you don't even notice. It was pretty straightforward:

[1] Move the erasing code to the output MC, which means it has to have a connection to the data pin of the memory chip.
[2] Connect the one unused pin on the output MC to that data pin.

It makes sense if you think about it - erasure only needs to be done after displaying the color, so it's the perfect place to put those lines of code. And I was able to use the freed-up space on the maximizer MC to make its second loop (the one that finds the position of the biggest value) only look over the part of the memory chip that's actually used by the shoes.
And with that - it's done! ¥22, 1043 average power. Honestly, it feels like I was working on that one for weeks! Joe's ideas tend to need more engineering than usual to put together, but I'm sure he'll love this. And honestly, I might buy a pair of these myself, once they hit the stores...



Ooh, tracksuits would be interesting. There's the little question of the washability of e-ink fabric, though. And how would you keep the control circuit safe on its trip through the wash, for that matter? Still, that's a problem for the hardware design side of things - not me.


P.S: My secret project is almost done, and I'm getting excited to share it with all of you! Here's a sneak peek at what to expect: